\chapter{Struktursicht}
\label{cha:konzept_struktursicht}
In diesem Kapitel wird das Konzept mit dem Fokus auf die Struktur der XCommander Erweiterung erarbeitet. Die Erarbeitung der Struktursicht erfolgt in drei Phasen. In der ersten Phase wird die Struktur der Komponentenarchitektur konzipert. Anschliessend wird die Struktur der XCommander Library und der XCommander Erweiterung basierend auf der gewählten Architektur konzipiert.


\section{Komponentenübersicht}
\label{sec:konzept_komponentenuebersicht}

Das Komponentendiagramm in \autoref{fig:komponentendiagramm} beschreibt die einzelnen Komponenten und Schnittstellen und zeigt wie sie im Gesamtsystem interagieren.
\begin{figure}[H]
   \centering
   \includegraphics[width=0.9\textwidth]{images/komponentendiagramm}
   \caption{Komponentendiagramm der Erweiterung}
   \label{fig:komponentendiagramm}
\end{figure}

\subsection{Komponenten}
\label{sec:konzept_komponentenuebersicht_komponenten}
Die Komponenten lassen sich in Browser"=Komponenten, Content und Extension Process Komponenten unterteilen.

\subsubsection{Browser-Komponenten}
\begin{itemize}
   \item \textbf{Browser:} Der Browser repräsentiert die Laufzeitumgebung in der die Erweiterung ausgeführt wird.
  \item \textbf{Browser \acrshort{api}:} Jeder Browser stellt seine eigene Browser \acrshort{api} zur Verfügung über die eine Erweiterung auf proprietäre und browserspezifische Funktionen zugreifen kann.
 \item \textbf{Web Content:} Der Web Content repräsentiert die aktuell geladene Webseite im Browser. 
\end{itemize}
 
\subsubsection{Komponenten im Extension Process}
\begin{itemize}
  \item \textbf{XCommander Extension:} Die Komponente XCommander Extension enthält erweiterungspezifische Logik und stellt diese indirekt über die Library der XCommander Content Extension zur Verfügung.
  \item \textbf{XCommander Library:} Die XCommander Library ist die Kern"=Komponente der gesamten Erweiterung. Sie kapselt browserspezifische Funktionen und stellt diese über browserunabhängige Schnittstellen der Erweiterung zu Verfügung.
\end{itemize}

\subsubsection{Komponenten im Content Process}
\begin{itemize}
  \item \textbf{XCommander Content Extension:} Die Komponente XCommander Content Extension enthält die eigentliche Erweiterung.
  \item \textbf{XCommander Content Library:} Die XCommander Content Library repräsentiert die XCommander Library als Proxy-Objekt im Content Process, damit Content Scripts auf die Library im Extension Process zugreifen können.
\end{itemize}

\subsection{Schnittstellen}
\label{sec:konzept_komponentenuebersicht_schnittstellen}
\begin{itemize}
  \item \textbf{Interface 1:} Diese Schnittstelle repräsentiert die Messaging"=Schnittstelle zwischen Extension und Content Process.
  \item \textbf{Interface 2:} Die XCommander Content Library stellt über diese Schnittstelle sogenannte Stub-Methoden der XCommander Library zur Verfügung. Somit kann die XCommander Content Extension via der XCommander Content Library auf sämtliche Library-Funktion aus dem Extension Process zugreifen. Die Kommunikation über diese Schnittstelle erfolgt immer asynchron.
 \item \textbf{Interface 3:} Die XCommander Library kann über diese Schnittstelle browserspezifische Funktionen der Browser \acrshort{api} aufrufen.
 \item \textbf{Interface 4:} Die XCommander Extension kann über diese Schnittstelle direkt auf Library Funktionen zugreifen.
\end{itemize}

\newpage
\section{XCommander Library}
\label{sec:konzept_xcommander_library}

Die XCommander Library lässt sich gemäss dem Erweiterungskonzept und dem Architekturansatz in zwei Komponenten aufteilen (\vgl{\autoref{fig:komponentendiagramm} - \nameref{fig:komponentendiagramm}}). Nachfolgend werden diese beiden Komponenten in Abhängigkeit des Prozesses, in dem sie Ausgeführt werden, konzipiert.

\subsection{Extension Process}
\label{subsec:konzept_extension_process}
Die XCommander Library bildet die Kern-Komponente der Library und wird im Extension Process der Erweiterung ausgeführt. Sie enthält die gesamte Logik der Library und stellt diese über den Message Port der XCommander Content Library zur Verfügung.

\begin{figure}[H]
   \centering
   \includegraphics[width=0.9\textwidth]{images/klassendiagramm_xcommander_library}
   \caption{Klassendiagramm der XCommander Library}
   \label{fig:klassendiagramm_xcommander_library}
\end{figure}

Das Klassendiagramm in \autoref{fig:klassendiagramm_xcommander_library} zeigt die Struktur der XCommander Library. Nachfolgend wird die Struktur und Funktionsweise der wichtigsten Klassen genauer erläutert.

\subsubsection{XCommanderEventListener}
Die \verb|XCommanderEventListener|"=Klasse ist nach dem Observer Pattern implementiert, auch bekannt als PubSub"=Pattern. Über die \verb|addEventListener()|"=Methode kann sich ein Objekt für ein bestimmtes Thema (\verb|type|) am Observer registrieren. Ruft ein anders Objekt die \verb|fireEvent()| Methode zu einem bestimmten Thema am Oberserver auf, benachrichtigt dieser automatische alle zu diesem Thema registrierten Objekte (gennant Listener). 

Das \verb|XCommanderMessaging|"=Objekt implementiert als Message Listener ein eigene Instanz der \verb|XCommanderEventListener|"=Klasse um eingehende Nachrichten zu verteilen.

\subsubsection{XCommanderMessageServer}
\acrshort{html}5 bietet mit der Web Messaging \acrshort{api} eine Möglichkeit das Webseiten Fenster-übergreifend (Cross Window Messaging) im Browser untereinander kommunizieren können (\vgl{\cite[]{w3c2011messaging}}). Das Erweiterungskonzept des Chrome, Safari und Opera Browser benutzen die Web Messaging \acrshort{api}, damit Content Scripts mit Scripts aus dem Extension Process kommunizieren können. Jeder der drei Browser implementiert in ihrem Erweiterungskonzept das Cross Window Messaging auf eine andere Art.

Die \verb|XCommanderMessageServer|"=Klasse repräsentiert einen generischen Message Server. Dieser kennt die  Messaging-Implementation einzelner Browser nicht. Der Message Server delegiert das Senden und Empfangen von Nachrichten an das generischen Browser-Objekt (\verb|XCommanderBrowser|). Der Message Server implementiert einen eigenen MessageListener (\verb|XCommanderEventListener|). 

\subsubsection{XCommanderStorage}
Die \verb|XCommanderStorage|"=Klasse repräsentiert eine Fassade des \verb|localStorage|"=Objekts. Die Fassade stellt einen vereinfachten Schnittstelle zum Speichern von Daten im lokalen Speicher des Browsers zu Verfügung.

Der \acrshort{html}5 Web Storage Standard erlaubt nur das Speichern von String"=basierten Key/Value Paaren (\vgl{\cite[]{w3c2009storage}}). Die Sichtbarkeit auf den lokalen Speichern wird durch die Domain limitiert, unter der ein Skript, Daten in den Speicher schreibt. Die \verb|XCommanderStorage|"=Klasse verfügt über Helper"=Methoden, die es erlauben \acrshort{json}"=Objekte zu speichern.

\subsubsection{XCommanderXHR}
Die \verb|XCommanderXHR|"=Klasse bietet eine vereinfachte Schnittstelle um interne oder externe Ressourcen wie Webservices zu verwenden. Moderne Browser unterliegen der \gls{same_orgin_policy} somit können Skripte nur \verb|XmlHttpRequests| an die Domain der aktuell geladenen Webseite richten. 

Die einzelnen Erweiterungskonzepte von Chrome, Safari und Opera unterstützen auch \gls{cross_site_scripting} in einem sicheren und kontrollierten Umfeld, damit eine Erweiterung auch externe Ressourcen anbinden kann. In der Manifest"=Datei können Rechte für beliebige Domains erteilt werden, um \gls{cross_site_scripting} für diese Domains zu erlauben.

\subsubsection{XCommanderBrowser}
Die abstrakte \verb|XCommanderBrowser|"=Klasse definiert die generische Browser"=Schnittstelle. Jeder Browser der durch die Library unterstützt wird, muss eine konkrete Implementation dieser Schnittstelle aufweisen und die Methoden \verb|createTab()|, \verb|navigateTo()|, \verb|getExtensionUrl()|, \verb|postMessage()| und \verb|log()| mit der Funktionalität ihrer proprietären Browser \acrshort{api} überschreiben.

Dank dieser Abstraktion erfolgt der Zugriff auf proprietäre Browser Methoden zentral in einer Klasse und erleichtert die Erweiterbarkeit der Library.
Für den Prototyp wurde die Schnittstelle gemäss den funktionalen Anforderungen auf ein Minimum reduziert.

Jede konkrete Implementierung überschreibt folgende Methoden:
\begin{itemize}
  \item{\verb|createTo()|} Diese Methode öffnet einen neuen Tab im Browser und lädt die angegebene Url.
  \item{\verb|navigateTo()|} Diese Methode navigiert im aktuellen Tab des Browsers zur angegebenen Url.
  \item{\verb|getExtensionUrl()|} Jeder Erweiterung wird zur Laufzeit eine eigene Extension Url (Domain) zugewiesen. Um Ressourcen innerhalb der Erweiterung lokalisieren zu können, liefert die Methode zum relativen Pfad einer Ressource den absoluten Pfad (Url) zurück.
  \item{\verb|postMessage()|} Diese Methode erlaubt das Verschicken von Nachrichten an Content Scripts. Die Messaging"=Klasse delegiert ausgehende Nachrichten an diese Methode der konkreten Browserimplementation.
  \item{\verb|log()|} Diese Methode erlaubt Fehler"= und Log"=Meldungen in die Konsole des Browsers zu schreiben.
\end{itemize}
Jeder konkrete Browser implementiert sein Browser \acrshort{api}"=abhängiges \verb|onMessage()|"=Event, um eingehende Nachrichten empfangen und an den Message Server weiterleiten zu können.

\subsubsection{XCommander}
Die \verb|XCommander|"=Klasse dient zur Instanzierung der einzelnen Library"=Klassen und stellt Instanzen dieser Klassen als Eigenschaften zur Verfügung. Nebenbei kann sie Helper"=Methoden beinhalten, die von allen Objekten in der Library benutzt werden können.

\newpage
\subsection{Content Process}
\label{subsec:konzept_content_process}
Die XCommander Content Library wird im Content Process ausgeführt und repräsentiert ein Proxy-Objekt der XCommander Library aus dem Extension Process. Das Proxy-Objekt enthält ausser dem Message Client keine eigene Logik. Zugriffe auf Library Funktionen werden über den Message Port an die XCommander Library im Extension Process delegiert.

\begin{figure}[H]
   \centering
   \includegraphics[width=0.9\textwidth]{images/klassendiagramm_xcommander_content_library}
   \caption{Klassendiagramm der XCommander Content Library}
   \label{fig:klassendiagramm_xcommander_content_library}
\end{figure}

\autoref{fig:klassendiagramm_xcommander_content_library} veranschaulicht das Design der XCommander Content Library. Ausser der \verb|XCommanderMessageClient|"=Klasse und der konkreten Browserklassen repräsentieren alle anderen Klassen sogenannte Stubs.

Die Stubs verbergen die Komplexität des Messaging Protokolls und bilden die Schnittstelle der Library ab. Dieses Entwurfsmuster hat den Vorteil, dass Content Scripts auf die XCommander Library zugreifen können ohne sich um das komplexe Messaging zwischen den beiden Prozessen kümmern zu müssen. Der Zugriff auf die XCommander Library erfolgt immer asynchron, da die darunterliegende Messaging \acrshort{api} und JavaScript im allgemeinen, asynchron implementiert ist. Somit kann jeder Methode, die via Messaging auf die Library zugreift, eine Callback-Methode mitgegeben werden, die nach der asynchronen Ausführung aufgerufen wird.
\section{XCommander Erweiterung}
\label{sec:konzept_xcommander_erweiterung}
Die XCommander Erweiterung besteht wie die Library aus einer Komponente im Extension und einer Komponente im Content Process. Im Gegensatz zur Library enthalten die Komponente der XCommander Erweiterung sämtliche grafische Benutzeroberflächen der Erweiterung. Nachfolgend werden diese beiden Komponenten in Abhängigkeit des Prozesses, in dem sie Ausgeführt werden, konzipiert

\subsection{Grafische Benutzeroberfläche}
\label{subsec:konzept_grafische_benutzerschnitstellen}
Die grafische Benutzeroberfläche lässt sich in zwei Kategorien aufteilen:
\begin{itemize}
  \item \textbf{\gls{front_end}:} Beim \gls{front_end} handelt es sich um das Kommandozeilen-Fenster in dem XCommands ausgeführt werden können.
  \item \textbf{\gls{back_end}:} Beim \gls{back_end} handelt es sich um die Einstellungsseite, über diese die XCommander Erweiterung administriert werden kann.
\end{itemize}

\subsubsection{\gls{front_end}}
Das \gls{front_end} der Erweiterung wird auf der Basis von Content Scripts konzipiert. Die gesamte Benutzeroberfläche wird mittels \acrshort{dom}"=Manipulation in eine bestehende Webseite injiziert.

\subsubsection{\gls{back_end}}
Das \gls{back_end} der Erweiterung ist gemäss dem Erweiterungskonzept eine lokale Webseite, die innerhalb der Erweiterung mittels \acrshort{html}, \acrshort{css} und JavaScript entwickelt wird. Das \gls{back_end} wird  im Extension Process der Erweiterung ausgeführt, trotzdem inkludiert es die XCommander Content Library um auf die XCommander Library zu zugreifen. Chrome und Opera würden den direkten Zugriff auf die XCommander Library unterstützen, der Safari Browser verfolgt bezüglich Option Pages eine andere Strategie und erlaubt den Zugriff nur via Messaging. 

\subsection{Das XCommand}
\label{subsec:konzept_das_xcommand}
Das \gls{front_end} der XCommander Erweiterung enthält grundsätzlich keine eigene Funktionalität. Die Idee der XCommander Erweiterung beinhaltet, dass die Funktionalität von XCommander durch beliebige XCommands erweitert werden kann. Dieses Konzept erfordert eine normierte Struktur für XCommands. In diesem Unterabschnitt wird die Struktur eines XCommands im Detail erläutert.

Ein XCommand ist ein JavaScript"=Objekt basierend auf einer normierten Struktur. Neben zwingenden Eigenschaften und Methoden kann ein XCommand auch optionale Methoden haben. XCommands sind JavaScript"=Dateien mit der Dateierweiterung ">xcmd"< oder ">js"<.

Die \autoref{tbl:struktur_xcommand_eigenschaften} beschreibt alle optionalen und erforderlichen Eigenschaften eines XCommands.

\begin{longtable}{p{0.16\textwidth}p{0.60\textwidth}p{0.14\textwidth}}
\caption{Eigenschaften eines XCommands} \label{tbl:struktur_xcommand_eigenschaften}\\
   \hline
   \textbf{Eigenschaft} & \textbf{Beschreibung} & \\
   \hline\rowcolor[gray]{0.9}
   \verb|name| & Aussagekräftiger und eindeutiger Name über den das XCommand identifiziert werden kann. & erforderlich\\
   \verb|version| & Versionsnummer des XCommands im Format {0.0}. & erforderlich\\\rowcolor[gray]{0.9}
   \verb|description| & Kurze Beschreibung der Funktionalität. & erforderlich\\
   \verb|help| & Kurze Beschreibung, wie das XCommand angewendet wird. (Die \verb|help|"=Eigenschaft akzeptiert auch \acrshort{html}"=formatierten Text.)  & erforderlich\\\rowcolor[gray]{0.9}
   \verb|author| & & \\\rowcolor[gray]{0.9}
   \verb|  name| & Name des Autors bzw. Entwicklers & erforderlich\\\rowcolor[gray]{0.9}
   \verb|  email| & Email"=Adresse des Autors bzw. Entwicklers & optional \\\rowcolor[gray]{0.9}
   \verb|license| & Eine Lizenz unter welcher das XCommand der Öffentlichkeit zu Verfügung gestellt wird. & optional\\
   \verb|homepage| & Url zur Homepage des Autors.& optional\\\rowcolor[gray]{0.9}
   \verb|update| & Url zur Update Manifest"=Datei (update.json) & optional\\
   \verb|icon| & Url zu einem Icon mit 16x16 Pixel das den Namen und die Funktion des XCommands unterstreicht. & erforderlich\\\rowcolor[gray]{0.9}
   \verb|arguments| & Array von Argument"=Objekten & optional\\\rowcolor[gray]{0.9}
   \verb|  role| & Semantische Rolle des Arguments & erforderlich\\\rowcolor[gray]{0.9}
   \verb|  nountype| & Noun Type des Arguments & erforderlich\\\rowcolor[gray]{0.9}
   \verb|  label| & Ein Label der anstelle des Arguments angezeigt wird, wenn dieses noch keinen Wert hat. & erforderlich \\
   \hline
\end{longtable}

\noindent Die \autoref{tbl:struktur_xcommand_methoden} beschreibt alle optionalen und erforderlichen Methoden eines XCommands.

\begin{longtable}{p{0.16\textwidth}p{0.60\textwidth}p{0.14\textwidth}}
\caption{Methoden eines XCommands} \label{tbl:struktur_xcommand_methoden}\\
   \hline
   \textbf{Methode} & \textbf{Beschreibung} & \\
   \hline\rowcolor[gray]{0.9}
   \verb|install()| & Diese Methode wird bei der Installation des XCommands aufgerufen und ausgeführt. Über diese Methode können z.B. Standardwerte für Argumente im Local Storage gespeichert werden. & optional\\
   \verb|deinstall()| & Diese Methode wird bei der Deinstallation des XCommands aufgerufen und ausgeführt. Über diese Methode können z.B. Standardwerte für Argumente wieder aus dem Local Storage entfernt werden. & optional\\\rowcolor[gray]{0.9}
   \verb|execute()| & Diese Methode wird beim Ausführen eines XCommands ausgeführt. Sie kann beliebige Funktionalitäten wie z.B. die Weiterleitung zu einer Url in einem neuen Tab haben. Der \verb|execute()|"=Methode wird jedes mal die aktuell geparsten Argumente in einem Objekt (\verb|args|) und das preview"=Objekt (\verb|preview|) übergeben.  & erforderlich\\\
   \verb|preview()| & Diese Methode wird bei jeder Eingabe in der Kommandozeile ausgeführt. Der \verb|preview()|"=Methode wird jedes mal die aktuell geparsten Argumente in einem Objekt (\verb|args|) und das preview"=Objekt (\verb|preview|) übergeben.  & erforderlich\\
   \hline
\end{longtable}

In der \verb|preview()|"=Methode wird die Funktionalität implementiert, die während dem Tippen in der Kommandozeile im Preview"=Bereich angezeigt werden sollen. Das \verb|preview|"=Objekt ist eine Referenz auf das \acrshort{dom}"=Element des Preview-Bereichs. Somit kann die Vorschau in der \verb|preview()|"=Methode nach Belieben manipuliert und angepasst werden. Das \verb|args|"=Objekt enthält immer die aktuell geparsten Argumente, diese können direkt in der \verb|preview()|"=Methode z.B. als Parameter für einen \verb|XmlHttpRequest| verwendet werden. Gleiches Prinzip gilt auch für die \verb|execute()|"=Methode. Nur wird dort die Funktionalität implementiert, die für die Ausführung des XCommands relevant ist.

Das \autoref{lst:xcommand_example} in \autoref{cha:beispiel_xcommand} veranschaulicht exemplarisch die Struktur eines einfachen XCommands mit allen optionalen und erforderlichen Eigenschaften und Methoden.